.. :validated: 3.2.0

Инструкция по настройке двусторонних доверительных отношений между MS AD и ALD Pro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Благодаря внедрению ряда решений, включая глобальный каталог ALD Pro, есть возможность настраивать двусторонние доверительные отношения. В отличие от **MS AD**, в **ALD Pro** направления доверия **MS AD** → **ALD Pro** и **ALD Pro** → **MS AD** реализованы разными механизмами.

Двусторонние доверительные отношения, предоставляют возможность общаться доменам ALD Pro и MS AD, решая ряд важных задач:

-  Авторизация пользователей доверенных доменах на рабочих станциях;
-  Доступ к сетевым ресурсам пользователей доверенного домена (веб сервер, файловый сервер, базы данных и т.д.);
-  Разграничение доступа к ресурсам доверенных доменов.

Как работают доверительные отношения MS AD и ALD Pro
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Технические требования
++++++++++++++++++++++++++

Версии **Windows Server** работающие с глобальным каталогом **ALD Pro**

**browse.dat** Файл в директории ``/var/lib/samba`` в **Samba** используется для хранения информации о браузере (Browser Information). Этот файл содержит данные о доступных ресурсах и службах в сети, которые могут быть предоставлены сервером **Samba**.

Глобальный каталог
++++++++++++++++++++++++

Для работы с глобальным каталогом, его необходимо установить согласно Руководству администратора Часть 1 - Обновление подсистем - 3.1.3. Обновление с установкой Глобального Каталога.

**share_info.tdb** Файл в директории ``/var/lib/samba`` в **Samba** представляет собой базу данных TDB, используемую для хранения информации о совместно используемых ресурсах (шарах) в Samba.

**winbindd_cache.tdb** Файл в директории ``/var/lib/samba`` в **Samba** представляет собой базу данных TDB, используемую для кэширования данных и запросов, выполняемых службой ``Winbind`` в рамках протокола аутентификации и авторизации в среде **Samba**.

**winbindd_idmap.tdb** Файл в директории ``/var/lib/samba`` в **Samba** представляет собой базу данных TDB, используемую для хранения информации о сопоставлении (маппинге) идентификаторов безопасности (SID) и POSIX UID/GID в процессе аутентификации и авторизации через Winbind.

Для просмотра содержимого файлов XXXX.tdb в Samba используется утилита ``tdbtool``. Пример команды для просмотра содержимого ``registry.tdb``:

**tdbtool registry.tdb dump**

На данный момент объекты из суб-доменов не синхронизируются в **Global Catalog** главного домена, как это сделано в **Windows**.

**Глобальный каталог ALD Pro** -- это отдельный экземпляр **LDAP**-сервера, в котором содержится копия всех объектов домена в схеме данных **Active Directory**. Глобальный каталог обеспечивает возможность поиска объектов (пользователей и групп) из стандартных оснасток **Windows**, что нужно для добавления субъектов доверенного домена в списки доступа на стороне **Windows**.

Для более удобного просмотра всех настроек Samba, **включая реестр**, можно использовать команду ``net conf list``

Команда ``net conf list`` в **Samba** используется для отображения текущей конфигурации **Samba**. Она выводит различные параметры и настройки, связанные с работой **Samba**, включая параметры глобальной секции smb.conf, информацию о доменах, настройки **Kerberos** и другие параметры.

Более подробную информацию о реестре можно найти по адресу

https://www.samba.org/~obnox/presentations/linux-kongress-2008/lk2008-obnox.pdf

Каждая служба устанавливает свой собственный уровень журнала отладки. Увеличение уровня журнала может предоставить больше информации о проблемах с ``Winbind``, ``Samba(smbd)`` или ``nmbd``

В **Global Catalog** попадают пользователи и группы только при наличии аттрибута **ipaNTSecurityIdentifier**, на основании которого генерируется аттрибут **ObjectSid** у объекта в **Global Catalog**.

Механизм поиска и добавления субъектов **ALD Pro** в списки ACL на стороне **Windows** работает следующим образом:

1. **Windows**-администратор при добавлении пользователя/группы в ACL с помощью стандартной оснастки выполняет поиск объектов в доверенном домене **ALD Pro**. Запрос направляется к глобальному каталогу на порт 3268/TCP (**LDAP**) с аутентификацией по Kerberos. Если **Kerberos**-аутентификация по какой-либо причине не сработает (например, время в доменах отличается более, чем на 5 минут), то оснастка Windows попытается выполнить NTLM-аутентификацию, поэтому пользователь увидит окно для ввода учетных данных.

2. После успешного поиска появится список объектов **ALD Pro** с отображением их ``uid`` (в случае пользователя) или ``cn`` (в случае группы).

3. При добавлении субъекта в список доступа, система безопасности Windows выполнит еще один запрос к контроллеру домена ALD Pro по протоколу SMB для дополнительной проверки, существует ли субъект с таким SID в домене. 

4. Для успешного выполнения указанного запроса на контроллере ALD Pro должны работать службы ``smbd`` и ``winbind``. Обработка запроса выполняется с использованием библиотеки **ipasam** (или **aldprosam** в случае доверительных отношений между доменами **ALD Pro**).

5. После получения подтверждения, что субъект с указанным SID существует в домене **ALD Pro**, система **Windows** добавит его в редактируемый список доступа.

Настройка двусторонних доверительных отношений
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Настройка и проверка перенаправления DNS ALD Pro
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Для работы доверительных отношений с компьютеров из домена ``ALD.company.lan`` должны разрешаться имена компьютеров из домена ``WIN.company.lan`` и наоборот. Если этого нет, то нужно сделать взаимное перенаправление **DNS**-зон.

**Настройка ALD Pro**

Добавление зоны перенаправления можно сделать из графического интерфейса **Роли и службы сайта** → **Служба разрешения имен** → **Перенаправление запросов**.

1. Имя зоны = имя домена **MS AD**;
2. Глобальные перенаправители = IP-адрес контроллера домена **MS AD**, с которым устанавливаются доверительные отношения;
3. Остальные поля и параметры оставить без изменений.

**Настройка MS AD**

Настройка контроллера домена **MS AD** осуществляется согласно официальным инструкциям к **MS AD**. (**Пуск** → **Оснастка “DNS”**):

1. Контекстное меню к “Серверы условной пересылки” → Создать сервер условной пересылки;
2. В поле “DNS-домен” ввести имя домена **ALD Pro**;
3. Добавить IP-адрес контроллера домена **ALD Pro** в блоке “IP-адреса основных серверов:”.

Установка двусторонних доверительных отношений между доменами
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1. Так же можно интерактивно смотреть, что происходит с ``winbind`` в момент старта службы для этого выполните поочередно команды ниже:

.. code-block:: bash

    systemctl stop  winbind.service
    winbindd -i -d 100

2. Если требуется повысить логирование только для определенного сервиса, в данном примере логирование включено "1" для всех сервисов, кроме ``winbind`` -- для него включен уровень "100" . **/etc/samba/smb.conf**

.. figure:: media/image21.png
  :name: image_21

.. code-block:: bash

    smbcontrol winbind debuglevel
    PID 26871: all:1 tdb:1 printdrivers:1 lanman:1 smb:1 rpc_parse:1 rpc_srv:1 rpc_cli:1 passdb:1 sam:1 auth:1 winbind:100 vfs:1 idmap:1 quota:1 acls:1 locking:1 msdfs:1 dmapi:1 registry:1 scavenger:1 dns:1 ldb:1 tevent:1 auth_audit:1 auth_
    json_audit:1 kerberos:1 drs_repl:1 smb2:1 smb2_credits:1 dsdb_audit:1 dsdb_json_audit:1 dsdb_password_audit:1 dsdb_password_json_audit:1 dsdb_transaction_audit:1 dsdb_transaction_json_audit:1 dsdb_group_audit:1 dsdb_group_json_audit:1

Распространенные проблемы SSSD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Отсутствие групп при выполнении команды id
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Проблема: нет групп при выполнении команды ``id username@FQDN_WindowsDomain`` или членов группы с ``getent group``.

**Решение**. Проверить количество объектов в домене **MS AD**
  
.. code-block:: bash

    # В Домене Active directory запустить Powershell и выполнить команду ниже
    (Get-ADObject -Filter *).count

Проверить диапазоны идентификаторов пользователей домена **MS AD**:

.. code-block:: bash

    # Для вывода списка доменных пользователей и их SID в домене Active Directory запустить Powershell и выполнить команду ниже
    Get-ADUser -Filter * -Property SID | Select-Object Name, SID

Если количество объектов или последняя часть SID некоторых доменных пользователей **MS AD** превышает 200 000 – выполнить расширение диапазона:

.. code-block:: bash

    #Показать текущие диапазоны (idrange) для всех доменов
    # Произвести аутентификацию
    kinit admin
    #Вывести список доступных диапозонов
    ipa idrange-find
    #Изменить id_range для домена windomain.lan к примеру до 500 000
    ipa idrange-mod WINDOMAIN.LAN_id_range --range-size=500000
    #Удаление всего кеша с контроллера домена и перезапуск службы sssd
    rm -f /var/lib/sss/db/* /var/lib/sss/mc/* && systemctl restart sssd

Долгое выполнение команды id 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Отключение FAST аутентификации
+++++++++++++++++++++++++++++++++++++

Для доступа к ресурсам ``windows`` с аутентификацией по **kerberos** (IIS, cifs, принтеры с общим доступом по smb) необходимо отключить у клиентских компьютеров FAST аутентификацию, так как **windows** её не поддерживает. Для этого на всех клиентах **ALD Pro**, где предполагается доступ, необходимо настроить глобальную политику **Групповые политики → Параметры компьютеров → Безопасность → FAST аутентификация**. Выставить параметр ``never``.

.. code-block:: bash

    #Выполните команду id с параметром –G(вывести все ID групп)- эта каманда игнорирует вложенность групп
    id -G  winuser@windomain.lan
    
    #Если команда отрабатывает быстро то требуется добавить в существующую секцию в /etc/sssd/sssd.conf на каждом контроллере домена -игнорирование вложенных групп
    [domain/alddomain.lan]
    ...
    ignore_group_members = true
    subdomain_inherit = ignore_group_members
    
    #Выполнить очистку кеша и произвести перезапуск службы sssd
    rm -f /var/lib/sss/db/* /var/lib/sss/mc/* && systemctl restart sssd

SSSD не удается подключиться к MS AD из-за ошибок с GSS-API
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Проблема: поставщик удостоверений **MS AD** правильно настроен в файле ``sssd.conf``, но **SSSD** не удается подключиться к нему с ошибками **GSS-API**.

**Решение**. **SSSD** может подключаться только к поставщику **MS AD**, используя его имя хоста. Если имя хоста не указано, **SSSD**-клиент не может разрешить IP-адрес хоста, и аутентификация завершается неудачей.

Например, при такой конфигурации:

.. code-block:: bash

    [domain/ADEXAMPLE]
    debug_level = 0xFFF0
    id_provider = ad
    ad_server = 172.16.0.1
    ad_domain = example.com
    krb5_canonicalize = False

**SSSD**-клиент возвращает этот сбой GSSAPI, и запрос аутентификации завершается неудачей:

.. code-block:: bash

    (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
    (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot determine realm for numeric host address)]

Чтобы избежать этой ошибки, необходимо установить для ad_server значение имени узла **MS AD** или использовать ключевое слово ``_srv_`` для использования обнаружения службы **DNS**.


Распространенные проблемы DNS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

**ALD Pro** (**FreeIPA**) использует BIND в качестве интегрированного **DNS**-сервера. Если есть подозрения, что с **DNS** что-то не так, необходимо проверить журналы, сгенерированные BIND.

.. code-block:: bash

    journalctl -u bind9-pkcs11.service

Если требуется создать tcp dump, необходимо воспользоваться командой:

.. code-block:: bash

    tcpdump -i eth0 -w /home/${USER}/$(date +%Y-%m-%d_%H-%M)_$(hostname).pcap

.. list-table:: Распространенные проблемы DNS
  :widths: 10 35 55
  :header-rows: 1
  :align: left

  * - №
    - Проблема
    - Решение
  * - 1
    - Не работает DNS resolving имен из новой подсети
    - Необходимо добавить новую подсеть в **trusted_network** на каждом контроллере домена ALD Pro (FreeIPA)

      /etc/bind/**ipa-ext.conf**

      **Пример:**

      .. code-block::

        ........................
        acl "trusted_network" {
          localnets;
          localhost;
          192.168.88.0/24;
          172.19.3.0/24;
          172.19.4.0/24;
          <НОВАЯ Подсеть>;
        };
  * - 2
    - Не работают рекурсивные запросы
    - Необходимо включить дополнительные опции на каждом контроллере домена ALD Pro (FreeIPA)

      /etc/bind/**ipa-options-ext.conf**

      **Пример:**

      .. code-block::

        allow-recursion { trusted_network; };
        allow-query-cache { trusted_network; };

Распространенные проблемы Trust Creation (Создание доверительных отношений)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. list-table:: Распространенные проблемы Trust Creation
  :widths: 10 35 55
  :header-rows: 1
  :align: left

  * - №
    - Проблема
    - Решение
  * - 1
    - Ошибка 3221225485 при создании доверительных отношений:
      
      **ipa: ERROR: Ошибка обмена данными с сервером CIFS: код "3221225485", сообщение "An invalid parameter was passed to a service or function." (оба значения могут быть "None")**
    - Проверить, что параметры реестра /var/lib/samba/registry.tdb – существуют и не были удалены. Для проверки выполнить команду **net conf list**. Если вывод пустой или есть увереность, что файл был поврежден, требуется повторно выполнить команду ipa-adtrust-instal, предварительно сделав копию файла конфигурацуии smb.conf **cp smb.conf{,_bkp}**, так как он будет перезаписан из шаблона.

Настройка производительности SSSD для крупных развертываний доверия
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Настройка игнорирования участников групп (ignore_group_members)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Извлечение информации о пользователях (``id <username@<ADdomain>``) и группах является трудоемкой операцией для демона служб системной безопасности (**SSSD**), особенно при развертывании **ALD Pro** с доверием к большому домену **MS AD**. Улучшить производительность можно, настроив, какую информацию и как долго **SSSD** извлекает из поставщиков удостоверений (``identity providers``).

**Предварительное требование**

Необходимы права ``root`` для редактирования конфигурационного файла ``/etc/sssd/sssd.conf``.

**Процедура**

1. Открыть конфигурационный файл ``/etc/sssd/sssd.conf`` в текстовом редакторе.

2. Добавить следующие параметры в раздел [домен] для домена **MS AD**. Если доменного раздела для домена **MS AD** еще нет, необходимо создать его.

.. code-block:: bash

    [domain/ald.example.com]
    ignore_group_members = true
    subdomain_inherit = ignore_group_members
    ...

3. Сохранить и закрыт файл ``/etc/sssd/sssd.conf`` на сервере.

4. Перезапустить службу **SSSD**, чтобы загрузить изменения конфигурации.

.. code-block:: bash

    systemctl restart sssd

ignore_group_members

Наиболее трудоемкой операцией является загрузка групп, включая их участников. Обычно на начальном этапе важно, членом каких групп является пользователь (``id aduser@ad_domain``), а не какие участники входят в конкретные группы (``getent group adgroup@ad_domain``). При установке для параметра ``ignore_group_members`` значения **True**, все группы отображаются как пустые, таким образом загружается только информация о самих объектах группы, а не об их членах, что обеспечивает значительное повышение производительности. Важно обратить внимание, что идентификатор ``aduser@ad_domain`` все равно вернет все правильные группы.

``subdomain_inherit_inherit``

Вышеуказанные параметры могут быть переданы в конфигурацию доверенных доменов **MS AD**. На данный момент единственным поддерживаемым методом является использование опции ``subdomain_inherit`` в разделе домена ``sssd.conf``. Имена любого из двух приведенных выше параметров могут быть указаны в качестве значения ``subdomain_inherit``, и они будут применяться как к основному домену (IPA), так и к поддомену **MS AD**.

Настройка таймаута конфигурации для плагина ipa-extdom на ALD Pro (FreeIPA)-серверах
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Клиенты **ALD Pro** не могут напрямую получать информацию о пользователях и группах из **MS AD**, поэтому серверы **ALD Pro** используют плагин ``ipa-extdom`` для получения информации о пользователях и группах **MS AD**, и эта информация пересылается запрашивающему клиенту.

Плагин ``ipa-extdom`` отправляет запрос в **SSSD** на получение данных о пользователях **MS AD**. Если информации нет в кэше **SSSD**, **SSSD** запрашивает данные у контроллера домена **MS AD (DC)**. Можно настроить значение таймаута конфигурации, которое определяет, как долго подключаемый модуль ``ipa-extdom`` ожидает ответа от **SSSD**, прежде чем подключаемый модуль отменит соединение и вернет вызывающей стороне сообщение об ошибке таймаута. Значение по умолчанию равно 10000 миллисекунд (10 секунд).

В следующем примере время ожидания настройки устанавливается равным 20 секундам (20000 миллисекунд).

**Предупреждение**

Необходимо соблюдать осторожность при настройке таймаута конфигурации:

Если задается слишком малое значение, например 500 миллисекунд, у **SSSD может не хватить времени для ответа**, и запросы всегда будут возвращать таймаут.

Если задается слишком большое значение, например 30000 миллисекунд (30 секунд), **один запрос может заблокировать подключение к SSSD на этот промежуток времени**. Поскольку **только один поток может подключаться к SSSD одновременно**, все остальные запросы от подключаемого модуля должны ждать.

Если **ALD Pro**-клиенты отправляют много запросов, они могут заблокировать все доступные рабочие процессы, настроенные для сервера каталогов на **ALD Pro**-сервере. Как следствие, сервер может быть не в состоянии ответить на какой-либо запрос в течение некоторого времени.

**Изменять время ожидания конфигурации рекомендуется только в следующих ситуациях:**

- Если клиенты **ALD Pro** при запросе информации о пользователях и группах **MS AD** часто получают ошибки таймаута до истечения их собственного таймаута поиска. Значение таймаута конфигурации слишком мало.
- Если сервер каталогов на **ALD Pro**-сервере часто блокируется, а утилита ``pstack`` сообщает, что многие или все рабочие потоки в это время обрабатывают запросы ``ipa-extdom``. Значение слишком велико.

**Предварительное требование**

Пароль менеджера каталогов **LDAP** (LDAP Directory Manager password)

**Процедура**

Используется следующая команда, чтобы настроить время ожидания настройки на 20000 миллисекунд:

.. code-block:: bash

    # ldapmodify -D "cn=directory manager" -W dn: cn=ipa_extdom_extop,cn=plugins,cn=config changetype: modify replace: ipaExtdomMaxNssTimeout ipaExtdomMaxNssTimeout: 20000

Настройка максимального размера буфера для плагина ipa-extdom на ALD Pro-серверах
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Клиенты **ALD Pro** не могут напрямую получать информацию о пользователях и группах из **MS AD**, поэтому серверы IdM используют плагин ``ipa-extdom`` для получения информации о пользователях и группах **MS AD**, и эта информация пересылается запрашивающему клиенту.

Можно настроить максимальный размер буфера для плагина ``ipa-extdom``, который регулирует размер буфера, в котором **SSSD** может хранить полученные данные. Если буфер слишком мал, **SSSD** возвращает ошибку ERANGE, и подключаемый модуль повторяет запрос с буфером большего размера. Размер буфера по умолчанию составляет 134217728 байт (128 МБ).

В следующем примере максимальный размер буфера устанавливается равным 256 МБ (268435456 байт).

**Предварительное требование**

Пароль менеджера каталогов **LDAP** (LDAP Directory Manager password)

**Процедура**

Используется следующая команда, чтобы установить максимальный размер буфера равным 268435456 байтам:

.. code-block:: bash

    # ldapmodify -D "cn=directory manager" -W dn: cn=ipa_extdom_extop,cn=plugins,cn=config changetype: modify replace: ipaExtdomMaxNssBufSize ipaExtdomMaxNssBufSize: 268435456

Настройка максимального количества экземпляров для плагина ipa-extdom на ALD Pro-серверах
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Поскольку клиенты **ALD Pro** не могут напрямую получать информацию о пользователях и группах из **MS AD**, серверы **ALD Pro** используют плагин ``ipa-extdom`` для получения информации о пользователях и группах **MS AD**, а затем пересылают эту информацию запрашивающему клиенту.

По умолчанию плагин ``ipa-extdom`` настроен на использование до **80%** рабочих потоков **LDAP** для обработки запросов от **ALD Pro**-клиентов. Если служба **SSSD** на **ALD Pro**-клиенте запросила большой объем информации о пользователях и группах **AD trust**, эта операция **может остановить службу LDAP**, если она использует большинство потоков LDAP. Если данная проблема возникла, можно увидеть аналогичные ошибки в файле журнала **SSSD** для домена **MS AD**, ``/var/log/sssd/sssd__your-ad-domain-name.com_.log``:

.. code-block:: bash

    (2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
    (2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
    (2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: Server is busy(51), Too many extdom instances running.

Можно настроить максимальное количество экземпляров ``ipa-extdom``, установив значение для параметра ``ipaExtdomMaxInstances``, которое должно быть целым числом больше 0 и меньше общего числа рабочих потоков.

**Предварительное требование**

Пароль менеджера каталогов **LDAP** (LDAP Directory Manager password)

**Процедура**

1. Извлечь общее количество рабочих потоков.

.. code-block:: bash

    # ldapsearch -xLLLD cn=directory\ manager -W -b cn=config -s base nsslapd-threadnumber
    Enter LDAP Password:
    dn: cn=config
    nsslapd-threadnumber: 16

Это означает, что текущее значение для ``ipaExtdomMaxInstances`` равно 13.

2. Отрегулировать максимальное количество экземпляров. В этом примере значение изменяется на 14:

.. code-block:: bash

    # ldapmodify -D "cn=directory manager" -W
    dn: cn=ipa_extdom_extop,cn=plugins,cn=config
    changetype: modify
    replace: ipaExtdomMaxInstances
    ipaExtdomMaxInstances: 14

3. Следить за производительностью сервера каталогов **ALD Pro** и, если она не улучшится, повторить эту процедуру и отрегулировать значение переменной ``ipaExtdomMaxInstances``.

Настройка SSSD в ALD Pro-клиентах для крупных доверительных развертываний IdM-AD
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Эта процедура применяет параметры настройки к конфигурации службы **SSSD** в **ALD Pro**-клиенте, чтобы увеличить время отклика при получении информации из большой среды **MS AD**.

**Предварительное требование**

Нужны права **root** для редактирования конфигурационного файла ``/etc/sssd/sssd.conf``.

**Процедура**

1. Определить, сколько секунд занимает один незакешированный вход в систему.

а) Очистить кэш SSD на **ALD Pro**-клиенте ``client.example.com``

Требуется предварительная установка ``apt install sssd-tools``

.. code-block:: bash

    [root@client ~]# sss_cache -E

b) Измерить сколько времени требуется для входа в систему в качестве пользователя **MS AD** с помощью команды ``time``. В этом примере из клиента **ALD Pro** ``client.example.com`` войти на тот же хост, что и пользователь ``ad-user`` из **ad**.example.com AD Domain

.. code-block:: bash

    [root@client ~]# time ssh ad-user@ad.example.com@client.example.com

Ввести пароль как можно скорее.

.. code-block:: bash

    Password:
    Last login: Sat Jan 23 06:29:54 2021 from 10.0.2.15
    [ad-user@ad.example.com@client ~]$

c) Выйти из системы как можно скорее, чтобы отобразить прошедшее время. В этом примере один некэшированный вход в систему занимает около 9 секунд.

.. code-block:: bash

    [ad-user@ad.example.com@client /]$ exit
    logout
    Connection to client.example.com closed.
    
    real 0m8.755s
    user    0m0.017s
    sys     0m0.013s

2. Открыть конфигурационный файл ``/etc/sssd/sssd.conf`` в текстовом редакторе.

3. Добавить следующие параметры в раздел [домен] для домена **MS AD**. Установить параметры ``pam_id_timeout`` и ``krb5_auth_timeout`` на количество секунд, которое занимает некэшированная логика. Если доменного раздела для домена **MS AD** еще нет, создать его.

.. code-block:: bash

    [domain/example.com/ad.example.com]
    krb5_auth_timeout = 9
    ldap_deref_threshold = 0
    ...

4. Добавить следующую опцию в раздел [pam]:

.. code-block:: bash

    [pam]
    pam_id_timeout = 9

5. Сохранить и закрыть файл ``/etc/sssd/sssd.conf`` на сервере.

6. Перезапустить службу **SSSD**, чтобы загрузить изменения конфигурации.

.. code-block:: bash

    systemctl restart sssd

Монтирование кэша SSSD в tmpfs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Демон служб системной безопасности (**SSSD**) постоянно записывает объекты **LDAP** в свой кэш. Эти внутренние транзакции **SSSD** записывают данные на диск, что намного медленнее, чем чтение и запись из оперативной памяти (RAM).

Чтобы повысить производительность, необходимо смонтировать кэш **SSSD** в оперативной памяти.

Кэшированная информация не сохраняется после перезагрузки, если кэш **SSSD** находится в оперативной памяти.

Это изменение безопасно выполнять на серверах **ALD Pro**, поскольку экземпляр **SSSD** на сервере **ALD Pro** не может потерять соединение с сервером каталогов на том же хосте.

Если выполнить эту настройку на **ALD Pro**-клиенте, и он потеряет подключение к серверам **ALD Pro**, пользователи не смогут пройти проверку подлинности после перезагрузки, пока не будет восстановлено подключение.

**Предварительное требование**

Нужны права ``root`` для редактирования файла конфигурации ``/etc/fstab``.

**Процедура**

Довольно много времени, затрачиваемого на обработку запроса, уходит на запись объектов **LDAP** в кэш. Поскольку кэш поддерживает полные свойства ACID, он выполняет синхронизацию диска с каждой внутренней транзакцией **SSSD**, что приводит к записи данных на диск. С положительной стороны, это гарантирует, что кэш всегда доступен в случае сбоя сети и будет доступен для использования после сбоя компьютера, но, с другой стороны, запись данных требует времени. Можно смонтировать кэш на ``ramdisk``, сократив затраты на ввод-вывод с диска, добавив в ``/etc/fstab`` в виде одной строки следующее:

.. code-block:: bash

    tmpfs /var/lib/sss/db/ tmpfs size=300M,mode=0700,rootcontext=system_u:object_r:sssd_var_lib_t:s0 0 0

Затем необходимо подключить каталог и перезапустить sssd после этого:

.. code-block:: bash

    mount /var/lib/sss/db/
    
    systemctl restart sssd

Важно настроить параметр размера в соответствии с требуемым IPA и размером каталога объявлений. Как правило, можно использовать **100 Мб на 10000 записей LDAP**.

Выполнение этого изменения на **ALD**-сервере немного безопаснее, чем на **ALD**-клиентах, поскольку экземпляр **SSSD** на сервере никогда не потеряет подключение к **ALD**-серверу, поэтому кэш всегда можно перестроить. Но в случае, если кэш был потерян после перезагрузки, и **MS AD** был недоступен из-за сетевой ошибки или аналогичного состояния, узел не смог бы вернуться к кэшированным данным о **MS AD** пользователях.

Плюсы: Операции ввода-вывода в кэше выполняются намного быстрее.

Минусы: Кэш не сохраняется при перезагрузках. Это означает, что кэш должен быть восстановлен после перезагрузки компьютера, но также и то, что ``cachedpassword`` теряются после перезагрузки.

Доступ пользователей ALD Pro к ресурсам MS AD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Создание сетевой папки в домене MS AD
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Контроллер домена не рекомендуется использовать для создания общих сетевых ресурсов. Он используется в примере для упрощения процесса.

Создать папку ``C:\Common``, в свойствах на закладке «Sharing» выбрать «Share» и в окне «Network access» выбрать «Share», оставив все по умолчанию.

.. figure:: media/image27.png
  :name: image_27

Если открыть окно «Common Properties\Sharing\Advanced Settings\Permissions», то будет видно, что по умолчанию на уровне SMB все пользователи имеют полные права.

.. figure:: media/image28.png
  :name: image_28

Но доступ к файлам регулируется также на уровне NTFS разрешений, которые настраиваются на вкладке «Common Properties\Security». Можно предоставить доступ к общей папке всем аутентифицированным пользователям, и это позволит пользователям **ALD Pro** редактировать файлы в папке, доказывая работу доверительных отношений в направлении **MS → ALD**.

.. figure:: media/image29.png
  :name: image_29

.. figure:: media/image30.png
  :name: image_30

.. figure:: media/image31.png
  :name: image_31

Подключение сетевой папки на рабочей станции под управлением Astra Linux
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Для подключения сетевой папки из домена **MS AD** в **Astra Linux** необходимо открыть проводник, кликнуть правой кнопкой мыши по узлу «Сеть» и выбрать команду «Новое место». Задать следующие параметры подключения:

В примере Windows Domain Controller именуется как **dc-1**.win.company.local

- Название: Common (любое)

- Адрес: smb://dc-1.win.company.local/Common

формат протокол://имя_сервера/название_общей_папки

.. figure:: media/image32.png
  :name: image_32

Необходимо обязательно проверить, что время на контроллерах **MS AD** и **ALD Pro** синхронизировано, т. к. для работы протокола **Kerberos** нужно, чтобы время всех участниках расходилось не более, чем на 5 минут.

Если нет необходимости настраивать прозрачную аутентификацию, то можно указать имя пользователя в формате:

.. code-block:: bash

    #имя пользователя
    ALD\admin
    #в формате
    ДОМЕН\имя_пользователя

Система предложит сохранить учетные данные в связке ключей, для работы с которой можно воспользоваться приложением seahorse «Пароли и ключи»

.. code-block:: bash

    # apt-get install seahorse
    # seahorse

.. figure:: media/image33.png
  :name: image_33

**Ограничение доступа по SID**

Сценарий, когда доступ к сетевому ресурсу предоставляется всем пользователям домена, является крайне редким. На практике обычно требуется предоставить доступ только строго ограниченной группе пользователей. Если воспользоваться окном «Select Users or Groups», можно обнаружить, что объекты доверенного домена **ALD Pro** найти не удается.

.. figure:: media/image34.png
  :name: image_34  

Стандартный механизм поиска объектов из доверенного домена работает через глобальный каталог, которого в обычной **FreeIPA** нет. Глобальный каталог -- это еще один **LDAP**-каталог, который должен быть доступен на порту 3268 и предоставлять данные обо всех объектах леса в определенной схеме данных. Не имея этой службы на стороне **FreeIPA**, доступ конкретным пользователям можно предоставить только по SID через **PowerShell**.

Посмотреть SID пользователя **ALD Pro** можно с помощью утилиты ``wbinfo`` на **ALD Pro** контроллере домена:

Используя wbinfo

.. code-block:: bash

    root@aldpro01:~# wbinfo -n 'ald\admin'
    S-1-5-21-896088827-1417987318-1335504985-500 SID_USER (1)

Используя ipa command

.. code-block:: bash

    root@ald01:~# ipa user-show admin --all | grep ipantsecurityidentifier
    ipantsecurityidentifier: S-1-5-21-896088827-1417987318-1335504985-500

Назначить права доступа можно командой ICACLS (Integrity Control Access Control List)

Наиболее популярные разрешения:

    r = чтение

    rx = Чтение, Выполнение, Список содержимого папки

    rxm = Чтение, Выполнение, Список содержимого папки, Запись, Изменение

    f = Полный доступ

    (OI) = Для этой папки и её файлов

    (CI) = Для этой папки и её подпапок

Таким образом, чтобы дать обычные права на чтение и запись на папку, используются разрешения (OI)(CI)rxm. Тогда команда будет выглядеть так:

.. code-block:: bash

    PS C:\Users\Administrator> ICACLS "C:\Temp" /grant "*S-1-5-21-896088827-1417987318-1335504985-500:(OI)(CI)rxm"

После добавления объектов в ACL, в стандартном окне безопасности они будут отображаться даже не по своим SID, а по привычным именам, т. к. для разрешения имен глобальный каталог не требуется.

Для упрощения администрирования в **MS AD** можно создать вспомогательные группы. Например, для администраторов **ALD Pro** в **MS AD** создается группа «WIN\ALD_Pro_Administrators», в эту группу добавляются SID группы «ALD\Admins» из доверенного домена **ALD Pro**. Далее при назначении прав доступа на общий сетевой ресурс можно будет использовать группу «WIN\ALD_Pro_Administrators».

Добавление пользователей и групп из ALD Pro домена в домен MS AD
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Процесс добавления пользователей из одного домена в другой осуществляется через доверительные отношения между доменами. По умолчанию в доверенных доменах **MS AD** используется **Global Catalog** для поиска пользователя или группы, однако **ALD Pro** версии ниже 2.0.0 по умолчанию не имеет глобальный каталог, по этой причине для добавления пользователя или группы из домена без глобального каталога в домен **MS AD** с глобальным каталогом, используется **PowerShell** скрипт.

При добавлении пользователя или группы в домене **MS AD** будет создан специальный объект Foreign Security Principal.

https://social.technet.microsoft.com/wiki/contents/articles/51367.active-directory-foreign-security-principals-and-special-identities.aspx#:~:text=A%20Foreign%20Security%20Principal%20(FSP,security%20groups%20and%20granted%20permissions.

**Порядок добавления пользователя или группы**

1. Посмотреть SID пользователя **ALD Pro** можно с помощью утилиты ``ldapsearch``:

.. code-block:: bash

    root@aldpro01:~# wbinfo -n 'ald\elena.kuznetsova'
    S-1-5-21-1784717832-1844364183-3442789864-1013 SID_USER (1)

2. На стороне **MS AD** необходимо создать Domain Local группу, куда можно добавит SID из домена **ALD Pro**

.. figure:: media/image35.png
  :name: image_35

3. На стороне **MS AD** на контроллере домена необходимо запустить скрипт

    <S-1-5-21-1784717832-1844364183-3442789864-1013>– SID пользователя или группы

    <CN=Contoso-Group-DL,CN=Users,DC=contoso,DC=dom >- Distinguished Name группы

.. code-block:: bash

    #SID Из леса ALD_Pro(Пользователь или группа)
    $AldSid = 'S-1-5-21-1784717832-1844364183-3442789864-1013'
    
    #Domain Local Group из леса Active Directory
    $DomainLocalGroupDN = 'CN=Contoso-Group-DL,CN=Users,DC=contoso,DC=dom'
    
    #Создание нового Directory Entry
    $group = New-Object DirectoryServices.DirectoryEntry("LDAP://$($DomainLocalGroupDN)")
    
    #Добавление AldSid в DomainLocal группу
    [void]$group.member.Add("<SID=$AldSid>")
    $group.CommitChanges()
    $group.Close()

После выполнения скрипта пользователь будет добавлен в группу и соответствующий объект Foreign Security Principal будет создан автоматически.

Теперь можно назначить Domain Local группу, к примеру, на файловые ресурсы, и все пользователи или группы внутри нее будут иметь доступ к ресурсу в домене **MS AD**.

.. figure:: media/image36.png
  :name: image_36

.. figure:: media/image37.png
  :name: image_37

Доступ пользователей MS Windows к ресурсам ALD Pro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Доступ к ресурсам ALD Pro пользователям из доверенного домена **MS AD** предоставляется через внешние группы.

На стороне ALD Pro пользователям из доверенного домена **MS AD** предоставляется доступ к ресурсам через внешние группы.

.. code-block:: bash

    # ipa group-add 'ad_administrators_external' --desc='Внешняя группа администраторов из MS AD' --external
    # ipa -n group-add-member 'ad_administrators_external' --external 'WIN.COMPANY.LOCAL\Domain Admins'

Внешние группы не имеют gid (являются не POSIX-группами), поэтому их нельзя использовать напрямую для предоставления доступа к сетевым файлам. Следует создать еще одну обычную POSIX-группу и включить в нее группу ``ad_administrators``.

Важно отметить, что добавление двустороннего доверия возможно в обычной инсталляции **FreeIPA**, даже не имея поддержки глобального каталога.

Установка глобального каталога (в ALD Pro 2.0.0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Склонировать репозиторий:

.. code-block:: bash

    # git clone --branch AD-39377-mvp1 https://git.astralinux.ru/scm/ad/aldpro-backend-global-catalog.git /opt/gc/

где

- git clone -- команда для клонирования репозитория

- AD-39377-mvp1 -- имя ветки, в которой содержатся необходимые исходные коды

- https://git.astralinux.ru/… -- адрес репозитория с кодом глобального каталога

- /opt/gc/ - имя папки, в которую нужно клонировать репозиторий

Запустить скрипт, который выполнит настройку глобального каталога в системе:

.. code-block:: bash

    # /opt/gc/ipa-gc-install.py --gc-cert-file /etc/ssl/freeipa/server.p12 --gc-pin 'AstraLinux_172' --disable-fast-preauth

где

- ipa-gc-install.py — имя файла со скриптом для настройки GC

- server.p12 — контейнер с сертификатом удостоверяющего центра и сервера

